Today's system on a chip (SoC) size, timing, and power requirements cannot be met under traditional synchronous clocking methodologies where a single clock controls all memory elements. While controlling an integrated circuit (IC) with multiple clocks helps in meeting those requirements, the asynchronous nature of the clocks brings about new challenges. Signals transmitted asynchronously from one clock domain to another do not have a predictable timing and therefore violate timing requirements that are easily met in synchronous interfaces. Analysis and verification of asynchronous interfaces for correct synchronization mechanisms in such designs have become an essential part of SoC design flows. Neglecting this aspect of verification, often leads to chip failure. This is now handled by a verification step known as clock domain crossing (CDC) verification.
A CDC-based design is a design that has one clock asynchronous to, or has a variable phase relation with, another clock. A CDC signal is a signal latched by a flip-flop (FF) in one clock domain and sampled in another asynchronous clock domain. Transferring signals between asynchronous clock domains may lead to setup or hold timing violations of flip-flops. These violations may cause signals to be meta-stable. Even if synchronizers could eliminate the meta-stability, incorrect use, such as convergence of synchronized signals or improper synchronization protocols, may also result in functional CDC errors. Functional validation of such SoC designs is one of the most complex and expensive tasks.
Within one clock domain, proper static timing analysis (STA) can guarantee that data does not change within clock setup and hold times. When signals pass from one clock domain to another asynchronous domain, there is no way to avoid meta-stability since data can change at any time.
To address clock domain problems due to meta-stability and data sampling issues, electronic chip designers typically employ several types of synchronizers. The most commonly used synchronizer is based on the well-known two-flip-flop circuit. Other types of synchronizers are based on handshaking protocols or FIFOs. In a limited number of cases it may be useful to employ dual-clock FIFO buffers or other mechanisms optimized for domains with similar clock frequencies.
To accurately verify clock domain crossings, both structural and functional CDC analysis should be carried out. Structural clock domain analysis looks for issues like insufficient synchronization, or combinational logic driving flip-flop based synchronizers. Functional clock domain analysis uses assertion-based verification to check the correct usage of synchronizers. SpyGlass® CDC, a product of Assignee is an example of an electronic design automation (EDA) tool for CDC verification.
Electronic chip designers check for CDC problems by running CDC checks while they develop the register-transfer-level (RTL) design. The designers specify CDC constraints identifying clock signals and parameters specifying clock frequency, clock-phase and clock source. The constraints also specify blocks and path to include or exclude from checking. The designers also create a waivers file that tells the CDC checker to ignore the specified issues.
Netlist level CDC verification is essential because transformations induced by timing-driven synthesis optimizations, as well as test-driven and power optimization-driven netlist modifications of the clock structures introduce new CDC issues. After RTL development, designers use an RTL compiler to flatten and optimize the logic and generate the netlist design. At the netlist level designers typically add design-for-test (DFT) features such as scan chains that can be used for chip connectivity testing and debugging. At this stage of the development cycle the designers are usually under pressure to complete the design quickly. The designers want to check for CDC issues quickly but CDC checking the netlist is currently a difficult time-consuming task. The netlist has different net names than the RTL design. The designer has to formulate new CDC constraints that refer to the net names in the netlist. Well-defined structures like multiplexors used to select between clocks may be difficult to identify in the netlist. Due to the application of CDC at different hierarchy levels in RTL and netlist, the constraints at RTL blocks may not be mapped independently of each other in the netlist. For example, clock constraints corresponding to two different RTL blocks may correspond to fanouts of the same clock at a higher hierarchy level. Thus, the netlist may have additional clock domain crossings not present in the RTL, may have clock domain crossings that don't map to RTL, and may have crossings that have become unsynchronized.
Electronic chip designers need an electronic design tool to help them CDC check a netlist quickly and easily.